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FTP Operation Over Big Address Records (FOOBAR) 
Status of this Memo 


This memo defines an Experimental Protocol for the Internet 
community. This memo does not specify an Internet standard of any 
kind. Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


This paper describes a convention for specifying longer addresses in 
the PORT command. 


Introduction 


This RFC specifies a method for assigning long addresses in the 
HOST-PORT specification for the data port to be used in establishing 
a data connection for File Transfer Protocol, FTP (STD 9, RFC 959). 
This is a general solution, applicable for all "next generation" IP 
alternatives, and can also be extended to allow FTP operation over 
transport interfaces other than TCP. 
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1. Background 


The PORT command of File Transfer Protocol allows users to specify an 
address other than the default data port for the transport connection 
over which data are transferred. The PORT command syntax is: 


PORT <SP> <host-port> <CRLF> 
The <host-port> argument is the concatenation of a 32-bit internet 
<host-address> and a 16-bit TCP <port-address>. This address 


information is broken into 8-bit fields and the value of each field 
is transmitted as a decimal number (in character string 
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representation). The fields are separated by commas. A port command 
is thus of the general form "PORT h1,h2,h3,h4,p1,p2", where hl is the 
high order 8 bits of the internet host address. 
To accommodate larger network addresses anticipated for all IP "next 
generation" alternatives, new commands and reply codes are needed for 
FTP. This memo addresses these needs. 

2. The LPRT Command 
The LPRT command allows users to specify a "long" address for the 
transport connection over which data are transferred. The LPRT 
command syntax is: 


LPRT <SP> <long-host-port> <CRLF> 


The <long-host-port> argument is the concatenation of the following 
fields; 


o an 8-bit <address-family> argument (af) 

o an 8-bit <host-address-length> argument (hal) 

o a <host-address> of <host-address-length> (hl, h2, ...) 
o an 8-bit <port-address-length> (pal) 

o a <port-address> of <port-address-length> (pl, p2, ...) 


The <address-family> argument takes the value of the version number 
of IP (see Assigned Numbers, STD 2, RFC 1340), or generally speaking, 


an Internet layer protocol. Relevant assigned IPng version numbers 
are: 

Decimal Keyword 

0) reserved 

Tes unassigned 

4 Internet Protocol (IP) 

5 ST Datagram Mode 

6 SIP 

7 TP/IX 

8 PIP 

9 TUBA 

10-14 unassigned 

15 reserved 
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The value of each field is broken into 8-bit fields and the value of 

each field is transmitted as an unsigned decimal number (in character 
string representation, note that negative numbers are explicitly not 

permitted). The fields are separated by commas. 


A LPRT command is thus of the general form 
LPRT af,hal,hl,h2,h3,h4...,pal,pl,p2... 


where hl is the high order 8 bits of the internet host address, and 
pl is the high order 8 bits of the port number (transport address). 


3. The LPSV Command 


The L(ONG) PASSIVE command requests the server-DTP to listen ona 
data port other than its default data port and to wait for a 
connection rather than initiate one upon receipt of a transfer 
command. The response to this command includes the address family, 
host address length indicator, host address, port address length, and 
port address this server is listening on. The reply code and text 
for entering the passive mode using a long address is 228 
(Interpretation according to FTP is: positive completion reply 2yz, 
connections x2z, passive mode entered using long address xy8). The 
suggested textual message to accompany this reply code is: 


228 Entering Long Passive Mode (af,hal,h1,h2,h3,h4...,pal,pl,p2...) 


4. Permanent Negative Completion Reply Codes 


The negative completion reply codes that are associated with syntax 
errors in the PORT and PASV commands are appropriate for the LPRT and 
LPSV commands (500, 501). An additional negative completion reply 
code is needed to distinguish the case where a host supports the LPRT 
or LPSV command, but does not support the address family specified. 
Of the FTP function groupings currently defined for reply codes 
(syntax, information, connections, authentication and accounting, and 
file system), "connections" seems the most logical choice; thus, an 
additional negative command completion reply code, 521 is added, with 
the following suggested textual message: 


521 Supported address families are (afl, af2, ..., afn) 
Where (afl, af2, ..., afn) are the values of the version numbers of 
the "next generation" or other protocol families supported. IP 


address noted earlier. 
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3% 


Rationale 


An explicit address family argument in the LPRT command and LPSV 
reply allows the Internet community to experiment with a variety of 
"next generation IP" alternatives within a common FTP implementation 
framework. (It also allows the use of a different address family on 
the command and data connections.) An explicit length indicator for 
the host address is necessary because some of the IPNG alternatives 
make use of variable length addresses. An explicit host address is 
necessary because FTP says it’s necessary. 


The decision to provide a length indicator for the port number is not 
as obvious, and certainly goes beyond the necessary condition of 
having to support TCP port numbers. Currently, at least one IPng 
alternative (TP/IX) supports longer port addresses. And given the 
increasingly "multi-protocol" nature of the Internet, it seems 
reasonable that someone, somewhere, might wish to operate FTP operate 
over Appletalk, IPX, and OSI networks as well as TCP/IP networks. 

(In theory, FTP should operate over *any* transport protocol that 
offers the same service as TCP.) Since some of these transport 
protocols may offer transport selectors or port numbers that exceed 
16 bits, a length indicator may be desirable. If FTP must indeed be 
changed to accommodate larger network addresses, it may be prudent to 
determine at this time whether the same flexibility is useful or 
necessary with respect to transport addresses. 


Conclusions 


The mechanism defined here is simple, extensible, and meets both IPNG 
and possibly multi-protocol internet needs. 
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8. Security Considerations 

Security issues are not discussed in this memo. 
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